A boot method is available for personal computers (PCs) which allows a PC to obtain its boot image from a network server instead of local storage media (such as floppy disks, hard drives, or CDROMs). This capability is commonly referred to as a preboot protocol. An example of such a preboot protocol is Preboot Execution Environment (PXE) by Intel Corporation. Units supporting this capability can boot an operating system even if there is no local storage media on the processing unit, or if that local storage media is unavailable (for example, if the media has not been prepared/formatted, or if the media is storing other information that cannot be modified).
This preboot protocol boot capability provides a great deal of flexibility. Since there is a preboot image that is downloaded (across the network) and executed, there is a capability for this preboot image to determine information about the processing unit that is booting, and make dynamic decisions (such as which OS boot image to pull from the network and boot).
Some of the preboot protocol capabilities are particularly interesting to PC manufacturers and software installers, since the processing units they are building/configuring may not have local storage media at all, or may have media that does not yet have an operating system loaded. In addition, in a manufacturing environment it may be necessary to boot with different operating system environments at various points in the process, since the diagnostic software, system preparation tools (such as CMOS configuration and flash programming software), and OS preload tools may run under different operating system environments.
There are several problems that arise, however when using the preboot protocol. They are described in detail herein below.
1. Movement of Processing Units between Servers within the Process
The process of configuring, testing, and preloading a processing unit is a sequential process that requires steps to be performed according to a predefined state flow. Since the processing unit being configured may be rebooted or powered down during the process, the sequence of steps to be performed for that particular processing unit as well as certain real-time information unique to that processing unit (such as which steps have been processed and other unique log information) must be kept in nonvolatile storage. In cases where there is no local storage media, the information would need to be kept on a server, in a storage area-that is unique for the processing unit being processed. A problem can occur, however, if during the process the processing unit needs to be moved from one server to another, and if the unique storage location is not accessible from both servers. Changing servers could be necessary if some of the servers are specialized for a particular type of activity in the process (such as preload servers which are able to quickly supply large amounts of data for preloading OS and applications, or debug servers that have specialized debug hardware or software). If the processing unit is moved to a new server, the real-time state information is no longer available. This would mean that the processing unit would need to start at the beginning of the process again.
2. Need to Support Multiple OS Boot Image Selection
Another complication is the fact that since during the process it may be necessary to boot with different operating system environments, the unique data storage area also has the information on which OS boot environment it will need to boot for the next operational step in the sequence if the processing unit being processed is moved to a new server, it will not only not have access to the previous state information, but will not be able to determine which OS boot image (based on the needed OS environment) it needs to boot for the current operation.
3. Self-Determination of a Unique Identifier for a Processing Unit
Another problem facing manufacturers and configurators is the self-determination of the identity of the processing unit during the pre-boot period. Having a unique identifier is imperative since the unique data storage area on the server will be accessed based on this identifier. Since the manufacturer may not have programmed a unique identifier (such as a Unit Type/Serial Number or a UUID (Universal Unique Identifier) into the processing unit, the only unique number that the processing unit can assuredly read is the MAC Address (Media Access Control Address as defined by the OSI Reference Model Standard) of the network card that is being used for the preboot protocol boot. The problem with using the MAC address of the network adapter as the unique identifier is that in some cases the network adapter may be reused between processing units being configured (for instance if the processing units do not ship to customers with the network adapter, and the network adapter is being used as a test device), or if the network adapter fails during the process and is replaced with another adapter.
4. Ability to Associate the Unique Identifier with Information Supplied by a Floor Control System
Also related to the above item, is the fact that most floor control systems in a manufacturing environment will control the process using information such as machine type and/or serial number (referred to as MTSN directory name information). The floor control system will have information such as the bill of material, and the sequence of configuration/test sequence and parameters required for the processing unit. This information will be stored on one of the process servers, and can only be referenced by the MTSN directory name (the floor control system does not know the MAC Address for the network card adapter since the MAC Address is programmed into the network card adapter, and is not externally visible/scannable).
As mentioned above, it cannot be assumed that the processing unit can determine its own MTSN directory name; it can only determine its current MAC Address. Therefore, there needs to be a mechanism for associating (and disassociating) a MAC Address with an MTSN directory name.
Accordingly, what is needed is a system and method for controlling real time process data in a preboot manufacturing environment that overcomes the above-mentioned problems. The present invention addresses such a need.